The present invention is applicable to third generation mobile radio systems, for example, and in particular to mobile radio systems of the Universal Mobile Telecommunications System (UMTS) type.
Mobile radio systems are generally covered by standards and the corresponding standards published by the corresponding standards bodies may be consulted for more information.
FIG. 1 outlines the general architecture of mobile radio systems, essentially comprising:                a radio access network (RAN) 1, and        a core network (CN) 4.        
The radio access network comprises network elements such as base stations 2 (BS) and base station controllers 3 (BSC) and communicates with mobile terminals 5 via an interface 6 and with the core network 4 via an interface 7. The core network 4 communicates with external networks (not specifically shown). Within the radio access network, the base stations communicate with the base station controllers via an interface 8.
In a UMTS type system, the radio access network is called the UMTS terrestrial radio access network (UTRAN), a base station is called a Node B, a base station controller is called a radio network controller (RNC), and a mobile terminal is called a user equipment (UE). The interface 6 is called the Uu interface, the interface 7 is called the Iu interface, the interface 8 is called the Iub interface, and an interface 9 between radio network controllers is called the Iur interface. The interface 6 is also called the radio interface and the interfaces 7, 8 and 9 are also called terrestrial interfaces.
The radio network controller that controls a given Node B is called the controlling radio network controller (CRNC) and has a load control and radio resource allocation role for each Node B that it controls. Thus FIG. 2 shows a CRNC controlling a set of Nodes B and the cells (not specifically shown) that are covered by those Nodes B.
For a given call relating to a given user equipment, there is a serving radio network controller (SRNC) having a control role for the call concerned. A Node B connected to the user equipment but not controlled by the SRNC communicates with the SRNC via the radio network controller that controls it, also known as the drift RNC (DRNC), via the Iur interface. This situation arises in macrodiversity transmission, also known as soft handover, for example (although not exclusively). Thus FIG. 3 shows an SRNC controlling a user equipment and communicating with the core network via the interface Iu, and a DRNC controlling the user equipment for radio links set up for cells controlled by that DRNC (these cells are not specifically shown).
The above systems must generally be able to support traffic whose quality of service (QoS) requirements may differ greatly. The quality of service architecture in a system such as the UMTS, for example, is defined in the Technical Specification 3GPP TS 23.107 published by the 3rd Generation Partnership Project (3GPP). This quality of service architecture is based on support services characterized by quality of service attributes. There are various support services, for example radio access bearer (RAB) services, radio bearer (RB) services and Iu bearer services. There are various quality of service attributes, for example traffic class, maximum bit rate, guaranteed bit rate, transfer delay, traffic handling priority, etc. There are four traffic classes, namely conversational application, streaming application, interactive application and background application traffic classes. The quality of service attributes other than the traffic class may also be different for different types of service in the same traffic class; for example, for the conversational traffic class, the transfer delay for a telephone service is less than the transfer delay for a videophone service, which in turn is less than the transfer delay for a web browsing service, for example, for the interactive traffic class, for example. The transfer delay is generally specified only for the conversational and streaming traffic classes and the traffic handling priority is generally specified only for the interactive traffic class.
A model has been defined for the terrestrial interface communications protocols in which a distinction is drawn between a radio network layer corresponding to functions related to radio access, which are independent of the technology used for transport over the terrestrial interfaces, and a transport network layer corresponding to functions related to transport, which depend on the technology used for transport over the terrestrial interfaces. As a general rule, two types of data may be communicated using these protocols, namely data corresponding to traffic sent or received by a user equipment (also known as user data), and data corresponding to signaling, necessary for the operation of the system. There are two types of signaling, namely signaling related to the radio network layer and signaling related to the transport network layer.
The signaling relating to the radio network layer corresponds to the following protocols, for example, which are also known as application protocols:                for the Iu interface, the Radio Network Application Part (RANAP) protocol, defined for example in the Technical Specification 3GPP TS 25.413 published by the 3GPP,        for the Iub interface, the Node B Application Part (NBAP) protocol, defined for example in the Technical Specification 3GPP TS 25.433 published by the 3GPP, and        for the Iur interface, the Radio Network Subsystem Application Part (RNSAP) protocol, defined for example in the Technical Specification 3GPP TS 25.423 published by the 3GPP.        
The RANAP protocol includes signaling relating to radio access bearer (RAB) set-up. The NBAP protocol includes signaling relating to radio link set-up for cells controlled by the SRNC. The RNSAP protocol includes signaling relating to radio link set-up for cells controlled by the DRNC.
Quality of service management in the above kind of system generally comprises quality of service management linked to radio access, which is independent of the technology used for transport over the terrestrial interfaces, and quality of service management linked to transport, which depends on the technology used for transport over the terrestrial interfaces.
Quality of service management linked to radio access is typical of code division multiple access (CDMA) systems, for example the UMTS, and includes mechanisms such as radio admission control, selection of appropriate transport formats on transport channels, etc. The exchanges of signaling defined in the application protocols outlined hereinabove generally enable the network elements concerned of the UTRAN to determine the quality of service constraints necessary for executing these quality of service management mechanisms linked to radio access. The main network element of the UTRAN affected by implementing quality of service management mechanisms linked to radio access is the RNC, in its SRNC role. This is because, on the basis of quality of service parameters that are signaled to it by the core network, using the RANAP protocol, the SRNC can decide which type of service is required and therefore translate the quality of service parameters into parameters that may be used to set up radio links between Nodes B and user equipments, if necessary via one or more DRNC, and then signal those parameters to the network elements concerned, namely the Node B, using the NBAP protocol, and the DRNC, using the RNSAP protocol.
Transport over the terrestrial interfaces is generally in packet mode to optimize the use of resources available for transmission over those interfaces. Packet mode was originally intended for non-real-time services (having no strict priority and/or time delay constraints), and additional mechanisms, including quality of service management mechanisms, for example, were introduced subsequently to enable packet mode additionally to support real-time services (having strict priority and/or time delay constrains), for example voice services. In the case of the UMTS for example, it is also necessary to introduce the real-time concept for packet services to deal with the “soft handover” problem, i.e. that of requiring the RNC to supply the sending times of the data to the various Nodes B controlling the cells to which the mobile is connected. These sending times take the form of radio frame numbers, and thus limit the maximum delay authorized for the transmission of data between the RNC and the Node B. For reasons of efficient power control and radio admission control, for example, the maximum delay cannot be set too high.
One transport technology used in the UTRAN is the asynchronous transfer mode (ATM) technology based on asynchronous time division multiplexing of small packets of fixed size known as cells. The ATM technology is covered by standards and the corresponding standards published by the corresponding standards bodies may be consulted for more information. Suffice to say that an ATM network may be modeled by means of an ATM layer and an ATM adaptation layer (AAL) between the ATM layer and users. The ATM layer is connection-oriented and transmits cells between a source and a destination over a logical connection also known as a virtual channel (VC). For application of the ATM technology to transport within the UTRAN, a specific AAL layer called the AAL2 layer is used for user data. When a user equipment communicates with the UTRAN, a corresponding logical connection (called an AAL2 connection) is set up over one or more of the terrestrial interfaces concerned of the UTRAN. In the case of the ATM technology, the mechanisms for managing the transport quality of service include, for example, connection admission control (to decide if the transmission resources are sufficient to accept a new AAL2 connection request whilst maintaining the guaranteed quality of service), and scheduling (queuing) for multiplexing AAL2 connections within a virtual circuit, for example as a function of priority.
Technologies other than the ATM technology may be used in the transport network, for example the Internet Protocol (IP) technology. The IP technology is also covered by standards and the corresponding standards published by the corresponding standards bodies may be consulted for more information. Once again, mechanisms for managing the transport quality of service may be provided in the case of the IP technology.
The present invention relates more particularly to managing the quality of service linked to transport, and even more particularly to mechanisms enabling the network elements concerned of the UTRAN to determine the quality of service constraints necessary for implementing quality of service management. In the absence of such knowledge, or in the event of insufficient knowledge, this quality of service management cannot be implemented optimally and the quality of service may be degraded to an extent that users find unacceptable.
On the basis of radio access bearer (RAB) parameters signaled to it by the core network using the RANAP protocol, the SRNC can decide what type of service is required for a user equipment and therefore which quality of service should be used in the transport network to transmit user data for that user equipment in the downlink direction over the Iub interface to the Node B (respectively over the Iur interface to the DRNC).
A problem nevertheless remains, that of the Node B (respectively the DRNC) knowing which quality of service should be used in the transport network to transmit user data for a user equipment in the uplink direction over the Iub interface (respectively in the uplink direction over the Iur interface and/or the downlink direction over the Iub interface).
A first solution to this problem is as follows. In the case of a transport network using the ATM technology, the signaling relating to the transport network layer includes the Access Link Control Application Part (ALCAP) protocol as defined in ITU T Specifications Q.2630 1 and Q.2630 2 published by the International Telecommunications Union (ITU), for example, and corresponding to successive versions of the 3GPP standard, respectively version R99 (for the ITU-T specification Q.2630 1) and the versions R4 and subsequently R5 (for the ITU-T specification Q.2630-2). The ITU T specification Q.2630 2 defines a quality of service parameter called the AAL type 2 requested type path that may take one of the following three values, as a function of the type of service: “stringent”, “tolerant” and “stringent bi level”. This parameter is transmitted by the CRNC (respectively the SRNC) to the Node B (respectively the DRNC) and enables the Node B (respectively the DRNC) to determine, within limits defined by these values, the quality of service constraints applicable to uplink transmission of user data over the Iub interface (respectively uplink and downlink transmission over the Iur interface).
However, this first solution may be applied only from version R4 of the 3GPP standard. It is not applicable to the R99 version, or to the R5 version if the transport network uses the IP technology. For example, in the current version of the standard, and in the case of a transport network using the IP technology, the signaling relating to the transport network layer is such that the Node B (respectively the DRNC) does not know which quality of service should be used in the transport network for uplink transmission of user data over the Iub interface (respectively uplink transmission over the Iur interface and/or downlink transmission over the Iub interface). Also, the three values for the AAL type requested type path parameter (see above) do not necessarily differentiate sufficiently between the available types of service, and therefore do not necessarily allow optimum implementation of the quality of service management mechanisms.
A second solution to the above problem is as follows. Under version R99 of the standard, failing a standardized solution, it would be possible to use a “proprietary” mechanism in the Node B (respectively the DRNC) to configure the transport priority for each type of service over the Iub interface (respectively the Iur interface). For example, the Node B (respectively the DRNC) could, on the basis of parameters transmitted by the CRNC (respectively the SRNC) using the ALCAP protocol, determine which connections are associated with voice services and assign them a high transport quality of service, and conversely assign a lower transport quality of service to connections associated with other types of service (for example web browsing, ftp, dedicated signaling, videotelephony, etc.).
However, this second solution may be applied only if the Node B (respectively the DRNC) and the CRNC (respectively the SRNC) are from the same manufacturer. It cannot be applied if those network elements are from different manufacturers.
The present invention adopts another approach to solving this problem. The present invention is based in particular on the following observations. Some quality of service parameters, such as parameters representative of the transfer delay and/or traffic handling priority, as defined for example in the above-mentioned Technical Specification 3GPP TS 23.107, are very important in guaranteeing the quality of service, for example the transport quality of service, within this kind of network. Now, parameters of this kind are already used for quality of service management linked to radio access. However, under the current version of the standard, and as outlined above, for managing the quality of service linked to radio access, knowledge of these quality of service parameters remains essentially localized to the SRNC. This is because, as mentioned above, on the basis of radio access bearer (RAB) parameters that are signaled to it by the core network (using the RANAP protocol), the SRNC can determine which type of service is required for a user equipment. The SRNC can then translate those parameters into parameters that may be used to set up radio links between the Node B and the user equipment, if necessary via one or more DRNC, and then signal those parameters to the network elements concerned, namely the Node B, using the NBAP protocol, and the DRNC, using the RNSAP protocol. These parameters include, for setting up radio links between Nodes B and user equipments, parameters such as transport format combination set (TFCS) or transport format parameters, and, if needed for multiplexing by the DRNC on common or shared transport channels, parameters such as traffic class and traffic handling priority.
However, under the current version of the standard, such signaling of transport format parameters generally cannot indicate quality of service constraints for the transport network layer, and such signaling of the traffic class and the traffic handling priority is effected only at the Iur interface (and not at the Iub interface), and only in the case of common or shared transport channels (and not in the case of dedicated channels). Also, this kind of signaling cannot indicate the quality of service constraints for the transport network layer, at least in terms of transfer delay. In particular, in distinguishing between different conversational class services, it does not allow a distinction to be made between services that require a short transfer delay (for example telephone services) and services that may tolerate longer transfer delays (for example videophone services).